Update documentation for wasi:filesystem:descriptor#link-at.#848
Update documentation for wasi:filesystem:descriptor#link-at.#848wingo wants to merge 2 commits intoWebAssembly:mainfrom
wasi:filesystem:descriptor#link-at.#848Conversation
It would have been nice for `linkat` to do just what POSIX does, but Windows includes the case of hard-linking a directory in EACCESS instead of the POSIX-prescribed EPERM.
| /// Fails with `error-code::no-entry` if the old path does not exist, | ||
| /// with `error-code::exist` if the new path already exists, and | ||
| /// `error-code::not-permitted` if the old path is not a file. | ||
| /// Behavior is as described by [POSIX |
There was a problem hiding this comment.
Would you mind keeping the previous description of failure modes, and adding this prose + link at the bottom with something like "for more information, see " ?
Laying out the common failure mode and meanings is reasonable in the docs, rather than (for the same reason we note the failure mode for hard links).
There was a problem hiding this comment.
I wonder if only mentioning a subset of error modes might confuse the reader as being exhaustive; that was certainly my confusion when I read this at first.
The case of hard links is different, because it refines POSIX.
There was a problem hiding this comment.
Ah that's a great point.
It's a bit crude but I really want to optimize for saving the user a dig down the rabbit hole if we know the answer for at least some of the platforms and corner cases. What do you think about a note that it is non-exhaustive?
There was a problem hiding this comment.
FWIW, the sockets interface describes the possible errors too. But phrases them as "Typical errors"
This communicates clearly what common failure modes the caller can expect, but also doesn't rigidly tie things down for the implementation.
It would have been nice for
linkatto do just what POSIX does, but Windows includes the case of hard-linking a directory in EACCESS instead of the POSIX-prescribed EPERM.